Reconfiguring a Lisp System as a Hybrid Lisp/(Java) Component

We describe our experience in converting OMAR, a large human-performance modeling simulation environment, originally written completely in Lisp, into Distributed OMAR [D-OMAR] a distributed, hybrid Lisp/Java system. In the resulting system: • The kernel simulation system (Core-OMAR) remains written purely in Common Lisp, and as such is able to take full advantage of the relevant features of Lisp. • Other modules of the system (e.g. the User Interface) are written in languages more appropriate to the requirements of those modules (typically Java). • The D-OMAR system presents itself to an external system as a fully functioning component in that system's embedded target language (e.g. JAVA or C++) and as such is able to take advantage of features in that language (for example, support for middle-ware or other mechanisms for inter-component communication). • The underlying technique (built on an internal socket-based, inter-process, message-passing serialization stream) is applicable to a broad range of Lisp-based systems. The result is a system that can be run nearly transparently in a range of external languages, with an assortment of middle-ware choices and on a variety of hardware platforms. 1. Background and Motivation The Operator Model Architecture (OMAR) is a simulation development environment designed to explore and model human multiple task behaviors. The central elements of the simulation environment include Lisp-based representation languages, graphical editors and browsers to support model development, and analysis tools to support model evaluation. OMAR has been used principally to examine teamwork situations in which small numbers of human players interact with one another and with complex equipment; air traffic control is typical of the situations modeled. (Further discussion of the OMAR system, with references, can be found in Appendix 1.) In the context of the present discussion, we note primarily that the original OMAR system was written in Allegro CommonLisp [ACL] with the GUI components written in CLIM. While the OMAR system has been successfully deployed as a large, wholly-Lisp system for several years, it became desirable to use OMAR with other systems and, in particular, in ways that took advantage of the current movement towards component-based systems built on distributed architectures. Of particular importance was the desire that OMAR be able to run on multiple hardware platforms and in webbased applications. Furthermore, it was clear that Lisp/CLOS provided overwhelming advantages in the core underlying simulation application (e.g. Lisp/CLOS provides full multiple-inheritance; dynamic class definition and allocation; full and natural object and class-reflectivity; rapid prototyping capabilities; etc.) As such, it was highly desirable that Lisp be retained as the implementation language for the simulation engine. However it was less clear that "peripheral" modules of the system were provided equal advantages by the use of Lisp. Particular areas of concern were: 1] The GUI system. Traditionally, the greatest impediment to the portability of Lisp systems has been the GUI/graphics component. This is primarily due to the highly platform-specific nature of graphics systems, whether the system uses a standard commercially available graphics package (e.g. CLIM) or it uses direct calls to platform-specific graphics toolbox. Furthermore, for various reasons in most available Lisp-based graphics toolkits it is difficult to build interfaces that adhere to the standards of modern GUIbased design. 2] Lack of direct middle-ware support. While some Lisp-based support for standard middle-ware protocols are even now becoming